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REMARKS 

Claims 1-3, 5-17, 19-27 and 38-67 are pending in the application. 

Claims 1-3, 5-17, 19-27 and 38-67 have been rejected. 

Claims 1, 8, 19, 38, 41, 43, 48, 51, 58, 61, 64, and 65 have been amended. 
Support for these amendments is found, at least, at FIGs. 2A and 3, as well as fflj [0034], 
[0035], and [0048]. 

Formal Matters 

Appreciation is expressed for the telephonic interview conducted on August 19, 
2009 between Examiner Jakovac and Shawn Doman. During the interview, the Beck 
reference was discussed with reference to the independent claims. The undersigned 
believes this paper is in harmony with the positions expressed during the interview. 

The Office Action states that the Specification fails to provide antecedent basis 
for the term "drop," which was amended into the claims in the response filed April 15, 
2009. See Office Action, p. 4. Applicants respectfully submit that this objection is 
overcome by the claim amendments made herein. 

Rejection of Claims under 35 U.S.C. £ 103(a) 

Claims 1-3, 5-17, 19-20, 22-27, 38, 40-48, 50-58 and 60-67 stand rejected under 
35 U.S.C. § 103(a) as purportedly being unpatentable over U.S. Publication No. 
2001/0014097 by Beck, et al. ("Beck"), in view of TCP/IP Illustrated, Volume 1: The 
Protocols ("TCP/IP"). Applicants respectfully traverse this rejection. 

Applicants respectfully submit that the proposed combination of Beck and TCP/IP 
fails to disclose each feature of claim 1, which has been amended to recite: 

1 . A system comprising: 

a virtual link bundle comprising a plurality of communication links, wherein 
the plurality of communication links is configured to couple a virtual 
network device to a first network device external to the virtual 
network device; 
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a first end of each of the communication links is configured to be coupled 

to the first network device; 
a second end of a first one of the communication links is configured to be 

coupled to a first virtual network device sub-unit within a virtual 

network device; 

a second end of a second one of the communication links is configured to 
be coupled to a second virtual network device sub-unit within the 
virtual network device; 

the first one of the communication links and the second one of the 

communication links provide redundant connections between the 
first network device and the virtual network device; 

the first network device comprises a plurality of ports; 

each of the ports is configured to communicate packets with a respective 
client; 

the first network device is configured to append a header to a packet 

before sending the packet to the virtual network device via one of 
the communication links; and 

the header identifies a one of the ports having received the packet. 

For example, Applicants respectfully submit that the proposed combination of Beck and 
TCP/IP fails to disclose a virtual link bundle comparable to the one recited in claim 1 . 
The claimed virtual link bundle comprises a plurality of communication links that is 
configured to couple a virtual network device and a first network device external to the 
virtual network device. A first end of each of the communication links is configured to be 
coupled to the first network device. A second end of the first communication link and a 
second end of a second communications link are configured to be coupled to a first 
virtual network device sub-unit and second virtual network device sub-unit, respectively, 
within the virtual network device. 

The Office Action compares Beck's processor node A to the claimed first network 
device and states that Beck's FIG. 2 discloses a plurality of communications links where 
a first end of each of the links is configured to be coupled to processor node A. Office 
Action, p. 5. However, Beck's FIG. 2 does not show a plurality of communications links 
configured to be coupled to processor node A. At best, Beck discloses a single network 
connection between processor node A's network interface 20a and Subnet SI. See Beck, 
FIG. 2 and U [0026]. Thus the cited portions of Beck fail to disclose that each of a 
plurality of communications links is configured to be coupled to a first network device. 
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Furthermore, the Office Action compares the Beck's cluster (shown in Beck's 
FIG. 2) with the claimed virtual network device. Office Action, pp. 5-6. Applicants note 
that processor node A is included within Beck's cluster. On the other hand, claim 1 has 
been amended to further clarify that the claimed network device (which is configured to 
be coupled to the claimed virtual network device via the claimed virtual link bundle) is 
external to the claimed virtual network device. Thus, claim 1 discloses a virtual link 
bundle configured to couple a network device that is external to a virtual network device 
to that virtual network device. Since Beck's processor node A is within Beck's cluster, 
Beck's Processor node A and cluster cannot be compared to the claimed network device 
and virtual network device respectively. 

Applicants note that even if, in an alternative interpretation of Beck, Beck's client 
processor (shown in Beck's FIG. 2) were compared with the claimed network device, the 
comparison would suffer from the same infirmity as illustrated above. That is, Beck's 
FIG. 2 also fails to show a plurality of communications links configured to be coupled to 
the client processor. Thus, FIG. 2's client processor also is not comparable to the claimed 
network device. 

Applicants respectfully submit that the proposed combination of Beck and TCP/IP 
also fails to disclose "the first network device comprises a plurality of ports," and "each 
of the ports is configured to communicate packets with a respective client," as claimed. 
The Office Action cites portions of Beck that disclose that "each processor node is 
associated with specific port numbers," as purportedly disclosing this feature. Office 
Action, p. 6. However, as noted above, Beck discloses processor nodes that each have a 
single network interface and a single connection to a subnet. The association of a 
processor node with multiple port numbers does not mean that the processor node 
comprises multiple ports, but instead means that the processor node can receive packets 
addressed to the multiple port numbers. The cited portions of Beck fail to disclose a 
network device having multiple ports, wherein each port is configured to communicate 
packets with a respective client. 

Applicants respectfully submit that the proposed combination of Beck and TCP/IP 
also fails to disclose "the first network device is configured to append a header to a 
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packet before sending the packet to the virtual network device," and "the header 
identifies a one of the ports having received the packet," as claimed. The Office Action 
also states that Beck discloses modifying a packet header. Office Action, p. 6. The Office 
Action goes on to posit that it would be obvious to combine the cited portions of Beck 
with features of TCP/IP "in order to identify the source port." Office Action, p.7. The 
Office Action states that "the format of the TCP header includes a source port number 
(i.e. identifies the receiving port)." See Office Action, p. 6. This argument is unclear to 
Applicants. Specifically, it is unclear why the Office Action would suggest modifying 
TCP/IP with Beck "to identify the source port" when, as acknowledged by the Office 
Action, the TCP header already includes a source port number. It is further unclear how a 
source port in a TCP header "identifies the receiving port," as claimed. 

Furthermore, the TCP/IP reference states "[e]ach TCP segment contains the 
source and destination port number to identify the sending and receiving applications." 
Office Action, p. 3. Thus, TCP/IP indicates that the source port value identifies the 
sending application's port number. This directly contradicts the Office Action's previous 
interpretation, which states that the source port number included in a packet header 
identifies a receiving port. 

Applicants respectfully submit that while Beck may disclose modifying a packet, 
such modification does not involve appending a header that identifies a port that received 
the packet. The Office Action quotes portions of Beck that disclose identifying the 
receiving node. Office Action, p. 3 (citing Beck, H [0007]). Beck discloses modifying a 
packet header to identify a destination node. See Beck, % [0009]. This is done because the 
packet arrives addressed to the cluster. See Beck, H [0008]. Since the packet does not 
include specification of a particular processing node in the cluster, Beck discloses 
selecting a node and modifying the packet header to include specification of the selected 
processor node. See Beck, flH [0008]-[0009]. However, as noted, Beck fails to disclose 
modifying the packet header to indicate which processor node of the cluster received it. 
The Office Action states that it would have been obvious to do so (by combining Beck 
with TCP/IP) in order "to uniquely identify each connection between. . .the receiving and 
sending processor nodes of Beck." Office Action, p. 3. However, Applicants respectfully 
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submit that it is unclear that doing so would provide any advantage or improvement to 
Beck. 

Regarding claim 8, Applicants respectfully submit that the proposed combination 
of Beck and TCP/IP fails to disclose each feature of claim, which has been amended to 
recite: 

8. A system comprising: 

a first virtual network device sub-unit comprising: 
a first interface; and 

a controller coupled to the first interface and configured to forward 
packets received via the first interface, wherein 
the first interface is identified by a first logical identifier, 
a second interface is identified by the first logical identifier, 
an interface bundle comprises the first interface and the second 
interface, 

the second interface is comprised in a second virtual network 
device sub-unit, 

the controller is configured to detect whether a packet was received 

via a virtual network device link, 
a first end of the virtual network device link is configured to be 

coupled to the first virtual network device sub-unit, 
a second end of the virtual network device link is configured to be 

coupled to the second virtual network device sub-unit, and 
the first interface is configured to filter out the packet from a 

packet flow being sent via the first interface if the packet 

was received via the virtual network device link. 

Applicants respectfully submit that the proposed combination of Beck and TCP/IP fails to 
disclose "a first end of the virtual network device link is configured to be coupled to the 
first virtual network device sub-unit [and] a second end of the virtual network device link 
is configured to be coupled to the second virtual network device sub-unit." The Office 
Action states that "Beck discloses that when a packet is received a determination is made 
whether the packet was sent to the cluster (i.e. via the virtual network device links of fig. 
2." Office Action, p. 2. As an initial matter, the Office Action fails to state which 
elements of Beck's FIG. 2 are being compared with the claimed virtual network device 
link. For the sake of this argument, Applicants assume the Office Action intends to 
compare the links between Beck's processor node network interfaces and Beck's subnet 
with the claimed virtual network device link. Applicants note that Beck's links have a 
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first end coupled to a network interface and a second end coupled to a subnet. This is in 
direct contrast to the claimed virtual network device link which has a first end configured 
to be coupled to a first virtual network device sub-unit and a second end configured to be 
coupled to a second virtual network device sub-unit. 

Applicants respectfully submit that the proposed combination of Beck and TCP/IP 
also fails to disclose "the first interface is configured to filter out the packet from a packet 
flow being sent via the first interface if the packet was received via the virtual network 
device link." The Office Action states that Beck's disclosure of determining which 
processor node to send an incoming packet to discloses dropping or filtering out a packet 
if it is determined that the packet was received via the virtual network device link. Beck 
discloses selecting a processor node and forwarding an incoming packet to that processor 
node if the packet is addressed to the cluster. See Beck, [0039]-[0041]. Applicants 
respectfully submit that the plain meaning of the claim term "filter out" and the written 
description both clearly indicate that the packet is not transmitted further if the packet is 
received by via the virtual network device link. Accordingly, Beck's disclosure of 
deciding which processor node to forward a packet to is not read on by Applicants' claim. 

For at least the foregoing reasons, Applicants respectfully request the Examiner's 
reconsideration and withdrawal of the rejections to claims 1 and 8, as well as claims 2, 3, 
5-7 and 9-17 (which depend therefrom), and an indication of the allowability of same. 
The arguments made above with respect to independent claims 1 and 8 apply with equal 
force to independent claims 19, 41, 51, 58, and 61, which include, among other features, 
features substantially similar to those recited in claims 1 and 8. Accordingly, Applicants 
respectfully request the Examiner's reconsideration and withdrawal of the rejections to 
these claims, as well as claims 20-27, 42-47, 52-57, and 62-67 (which depend therefrom) 
and an indication of the allowability of same. 

Regarding claim 38, the cited portions of Beck fail to teach or suggest sending a 
first packet via a first link of a virtual link bundle, if a destination identifier associated 
with the first packet identifies the virtual link bundle, and sending a second packet via a 
second link of the virtual link bundle, if a destination identifier associated with the 
second packet identifies the virtual link bundle, where a single network device performs 
both the sending the first packet and the sending the second packet, the first link is 
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coupled to a first virtual network device sub-unit, the second link is coupled to a second 
virtual network device sub-unit, and the destination identifiers associated with the first 
and second packets, respectively, identify the same destination. 

The Office Action states that Beck's [0039-0041] and FIG. 2 disclose that 
processor node A sends packets to both processor nodes B and C. Office Action, p. 15. 
The cited paragraphs merely disclose determining whether a connection already exists to 
forward a received packet, and if not, which processor node in the cluster should be 
selected to establish a connection for the packet. Nothing in the cited paragraphs or figure 
teaches or suggests that a network device can send a first packet via one link, a second 
packet via a second packet, and that both packets are associated with identifiers that 
identify the same virtual link bundle. 

Furthermore, Beck discloses that if a connection exists, i.e., if a destination has 
previously been associated with a particular processor node, packets associated with the 
connection are transferred to the associated processor node. See Beck, D [0045]. Thus, 
Beck discloses that packets sent to the same destination are processed by the same 
processor node. This is in direct contrast to claim 38, which recites that a first and second 
packet associated with the same destination identifier are sent to different virtual network 
device sub-units. 

For at least the foregoing reasons, claim 38 is patentable over the cited art, as are 
its dependent claims 39-40. Claims 48-50 and 58-60 are patentable over the cited art for 
similar reasons. 

Claims 21, 39, 49 and 59 stand rejected under 35 U.S.C. § 103(a) as purportedly 
being unpatentable over Beck in view of TCP/IP, further in view of U.S. Patent No. 
6,735,205 issued to Mankude, et al. ("Mankude"). Applicants respectfully traverse this 
rejection. For at least the reasons presented above with reference to independent claims 
19, 38, 48, and 58, Applicants respectfully request the Examiner's reconsideration and 
withdrawal of the rejections to these claims and an indication of the allowability of same. 
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CONCLUSION 



In view of the amendments and remarks set forth herein, the application and the 
claims therein are believed to be in condition for allowance without any further 
examination and a notice to that effect is solicited. Nonetheless, should any issues 
remain that might be subject to resolution through a telephonic interview, the Examiner is 
invited to telephone the undersigned at 512-439-5092. 

If any extensions of time under 37 C.F.R. § 1. 136(a) are required in order for this 
submission to be considered timely, Applicants hereby petition for such extensions. 
Applicants also hereby authorize that any fees due for such extensions or any other fee 
associated with this submission, as specified in 37 C.F.R. § 1.16 or § 1.17, be charged to 
deposit account 502306. 



Respectfully submitted, 




Shawn Doman 
Attorney for Applicants 
Reg. No. 60,362 
Telephone: (512) 439-5092 
Facsimile: (512)439-5099 
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